ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group94a.txt/000095_icon-group-sender _Fri Apr 22 09:58:30 1994.msg

Internet Message Format | 1994-08-19 | 3KB

Received: by cheltenham.cs.arizona.edu; Fri, 22 Apr 1994 12:35:30 MST
From: Nevin Liber <nevin@caslon>
Message-Id: <[e-mail]>
Subject: Re: is this a bug?
To: [e-mail] (Icon Group)
Date: Fri, 22 Apr 1994 09:58:30 -0700 (MST)
Cc: [e-mail] (Jan Peter de Ruiter)
In-Reply-To: <[e-mail]> from "Jan Peter de Ruiter" at Apr 22, 94 01:06:56 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2482
Status: R
Errors-To: [e-mail]

Jan Peter de Ruiter proudly drove the following message along the Information SuperHypeway(TM) at breakneck speeds:

> procedure main()
>     t := table([]) # a table with default element []
>     every put(t[1],generate(1,5)) # fill t[1], which is empty list
>     every put(t[2],generate(6,9)) # fill t[2], which is empty list
>     every(write(!t[1])) # write out all elements of t[1]
>     write()
>     every(write(!t[2])) # write out all elements of t[2]
>     write(ximage(t)) # write out image of t
> end
>
> procedure generate(a,b)
>     every suspend (a to b)
> end

>{Expectation:  t[1] <- [1,2,3,4,5], t[2] <- [6,7,8,9]}
>{Result: (t[1] === t[2]) <- [1,2,3,4,5,6,7,8,9]]}

> Now my question is: have I understood the icon
> semantics wrongly, or is this a bug?

It is part of the semantics, and not a bug.

>If anyone
> understands what is happening here, could (s)he
> please explain?

Let xDefault = the default value of the table (in this case, []).

You were expecting copy(xDefault) to be returned; however, xDefault is
returned instead.  For structure types (lists, records, sets and
tables), operations on expressions that have the same value as
xDefault do their work on the same structure.  In other words, the
compare values operator (===) will always be true when getting the
xDefault element out of the table.

In your case, you never assign anything to the table, so t[1] and t[2]
always return the same default list.


BTW, even if tables had copy semantics for the xDefault element, the
above program still wouldn't work.  Since nothing is ever assigned to
the table, t[1] and t[2] would always return a copy of an empty list,
and the observable result of the above code would be:

    ((t[1] <- []) ~=== (t[2] <- []))

[Actually, t[1] and t[2] are never defined; the above is if you did an
assignment like

    t1 := t[1]
    t2 := t[2]

and looked at t1 and t2.]


Just wondering:  can anyone think of a situation where copy semantics
would be desirable?


What you really were expecting is the first time you referenced an
element in a table, copy(xDefault) is assigned to that element.
However, I don't believe that the benefits of this outweigh the
consequences of having these semantics (eg: describing how tables work
and what is and isn't a key of that table would be a nightmare to try
and describe).
--
    Nevin ":-)" Liber    [e-mail]    [phone]
                                                  +++ (520) after 3/95
                                      office:    [phone]